Repository navigation
Imaging and metadata tools for security-ir, held by forensic argument rules - #17
Conversation
Phase 10, step 5 plan, PR 3b (decision D14i). Imaging and metadata
tools need rules a list of options cannot express; codebud/forensic.py
holds them, and the safety engine applies them wherever a profile
allow-lists the tool, behind wrappers too (complete mediation).
- dc3dd: input an image file inside the project, never a device;
every output and log inside the project; hash= and log=/hlog=
required (NIST SP 800-86 section 4.2.2, ACPO principle 3); wipe=,
hwipe=, pat=, tpat= and unknown keys refused.
- ewfacquire: -u required, and with it the case metadata on the
command line (-C -e -E -D), -d with sha256, -l, the target (and a
second one) inside the project, the source an image file inside the
project; unknown options refused. The plan said to refuse -u, but
without it ewfacquire prompts on stdin, which a step cannot answer;
requiring the metadata flags meets the plan's concern (metadata
skipped) instead.
- exiftool: reading only. Its format strings (${...}), -if and
-config run Perl, and =, < and > write, copy or rename tags: those,
and the options that write, run code or read arguments from a file,
are refused; read options and tag names (-Artist) are allowed.
Paths are judged with symlinks followed. The rules come from the man
pages; none of the tools is installed on the dev machine, so they are
tested as rules, not against the binaries. Manual (Safety and Sandbox),
architecture layout, build list and test list updated.
Phase 10, step 5 plan, PR 3b. security-ir gains the imaging and
metadata tools, now that forensic.py keeps them to evidence handling:
- powerful (asked every time): dc3dd and ewfacquire, on image files
inside the project only -- re-imaging and converting (raw to E01),
hashed and logged;
- harmless (they only read): ewfverify, ewfinfo, exiftool.
Acquisition from devices stays with the operator, outside codebud
(NIST SP 800-86 section 4.2.1): dc3dd from /dev, dd, and exiftool
writes stay refused; tests pin that. Manual (Configuration >
Profiles) and NEWS updated.
Review summary: changes requestedOne full sweep over Conditions (
Correct, verified by tests:
De Morgan: allowed, but destroys evidence. Reproduced on
Limit, stated in the manual's general section: a file swapped in the instant between the check and the start isn't caught. Verdict: changes requested. The fix comes as a new commit, then a re-review. |
Review of PR #17. The rules only required outputs to be inside the project and not a device, so an imaging step could overwrite evidence: `dc3dd if=evidence/disk.raw of=evidence/disk.raw ...` truncated the source image, of= or hof= could replace another evidence file, log= could be the image itself, and ewfacquire's -l, -t or -2 likewise. Every dc3dd output and log, and ewfacquire's log, target and second target, must now be a path that does not exist yet -- which also rules out the input, since it exists. For an ewfacquire target, a base name, its segment files (.E01, .Ex01, ...) must not exist either. Nine new cases, all allowed before. Manual updated.
Re-review summary: fixed, ready to merge once CI passesSecond sweep over
New in this sweep, correct: existence is checked with Limit (documented): a file created or swapped in the instant between the check and the start isn't caught. 1454 tests pass, ruff is clean, the manual builds without warnings, and |
|
Merging. The review finding (outputs could overwrite evidence) is fixed and re-verified: every output, target and log must be a new file. CI passes on all five jobs at A standing caveat, stated in the PR: the rules come from the tools' man pages and are tested as rules, not against the binaries, since none is installed on the dev machine. Next, from the step 5 plan: PR 4, target extraction for network tools and the hard scope block (codebud_sec). |
PR 3b of the phase 10, step 5 plan (decision D14i): imaging and metadata tools for security-ir. Each is held by rules a list of options can't express.
Commits
1a3da08feat(safety): argument rules for dc3dd, ewfacquire and exiftool (codebud/forensic.py; applied by the safety engine, behind wrappers too).dc3dd: input must be an image file inside the project, never a device. Outputs and logs must be inside the project.
hash=and a log are required.wipe=/hwipe=/pat=/tpat=and unknown keys are refused.ewfacquire:
-uis required, together with the case metadata-C -e -E -D,-d sha256and-l. The target and any second target must be inside the project, and the source must be an image file inside the project. Unknown options are refused.A deliberate change from the plan, which said to refuse
-u: without-u, ewfacquire prompts on stdin, which a step can't answer. Requiring the metadata flags meets the plan's concern (metadata skipped) instead.exiftool: reading only.
=,<,>(write, copy or rename tags) and${…}(Perl).-o,-overwrite_original,-tagsFromFile,-p,-if…,-config,-api,-@,-w…,-execute, …).exiftool -Artist photo.jpg).c957616feat(security-ir): image files and metadata, within the forensic rules.dc3dd,ewfacquire.ewfverify,ewfinfo,exiftool.Testing
1445 tests pass, 60 of them new across
test_forensic_rules.pyandtest_security_ir.py. Ruff is clean, the manual builds without warnings, andmake distcheckpasses.Not tested against the binaries: none of the four tools is installed on the dev machine. The rules come from their man pages (dc3dd(1), ewfacquire(1), exiftool(1)) and are tested as rules.